Course: React Native Training
Topic: Preparing iOS Applications for App Store Submission
Course Link: React Native Training at JustAcademy
Demo Link: Register for a Course Demo
JustAcademy Website: Visit JustAcademy
Preparing an iOS application for App Store submission is an important stage in the React Native development lifecycle. After developing and testing an application, developers must configure its identity, prepare a production build, manage signing credentials, create the App Store listing, provide screenshots and descriptions, complete privacy information, and submit the application for Apple's review.
React Native allows developers to build cross-platform applications using JavaScript or TypeScript and native platform capabilities. However, an iOS application must still comply with Apple's technical, security, privacy, design, and distribution requirements before it can be released publicly.
For Expo-based React Native applications, developers can use Expo Application Services (EAS) Build to generate production binaries and EAS Submit to upload them to App Store Connect. Alternatively, developers can build and upload applications through Xcode on macOS.
Publishing an iOS application involves several connected stages. Completing the development work alone is not sufficient; the application must also be packaged, signed, uploaded, described, tested, and approved for distribution.
React Native App Development
|
v
Functional and Device Testing
|
v
Configure Bundle ID and Version
|
v
Prepare Icons, Permissions and Privacy
|
v
Configure Signing Credentials
|
v
Create Production iOS Build
|
v
Upload to App Store Connect
|
v
TestFlight Testing and Validation
|
v
Complete Store Listing and Compliance
|
v
Submit for Apple App Review
|
v
Approval and App Store ReleaseA paid Apple Developer Program membership is generally required to submit an application to the Apple App Store. The account provides access to the developer resources, signing capabilities, and distribution services required for publishing.
Before starting, confirm that:
| Tool or Resource | Purpose |
|---|---|
| Node.js | Runs the JavaScript tooling used by the React Native project. |
| npm, Yarn, or pnpm | Installs and manages project dependencies. |
| React Native or Expo project | Contains the application source code and configuration. |
| EAS CLI | Configures and manages cloud builds and submissions for supported workflows. |
| Xcode | Builds, archives, signs, and uploads iOS applications locally on macOS. |
| Apple Developer account | Provides the membership and signing resources required for distribution. |
| App Store Connect | Manages the application listing, builds, testing, review, and release. |
| TestFlight | Distributes eligible beta builds to testers. |
| Git | Tracks source changes and helps reproduce release versions. |
When using EAS Build and EAS Submit, cloud services can handle many build and upload operations without requiring a local Mac. A Mac with Xcode is needed for the traditional local Xcode archive workflow.
Before preparing the release, open the project directory and install dependencies using the package manager associated with the project.
cd MyReactNativeApp
npm installFor Expo projects, run the following checks:
npx expo-doctor
npx expo startResolve relevant dependency and configuration warnings, then test the application locally. Do not assume that a successful development session guarantees that the production build will succeed.
Before creating a production build, verify that the main user journeys are complete and reliable.
A release build should not expose development menus, test credentials, debug endpoints, mock production data, or temporary navigation routes. Review all development-only settings before publishing.
if (__DEV__) {
console.log("Development-only diagnostics");
}The example shows a basic development-only conditional. Production security must not rely solely on hiding a menu or disabling a log statement. Remove secrets from the client bundle and enforce access control on the server.
Check that all dependencies support the project's React Native and Expo versions. Native libraries should be compatible with the target iOS environment and configured correctly for release builds.
The bundle identifier is a unique string that identifies an iOS application. It commonly follows a reverse-domain naming convention, such as com.company.application.
The identifier connects the application configuration with Apple's app registration, signing setup, and App Store Connect record. For an existing published application, changing the identifier generally creates a different app identity rather than updating the existing listing.
In an Expo project, define the identifier in app.json or the corresponding app configuration file.
{
"expo": {
"name": "TrainingApp",
"slug": "training-app",
"version": "1.0.0",
"ios": {
"bundleIdentifier": "com.example.trainingapp"
}
}
}The bundle identifier above is only an example. Replace it with a unique identifier controlled by your organization.
The application name shown to users should be clear, recognizable, and consistent with the product's branding. In Expo, the name field provides the display name used in supported app configuration workflows.
{
"expo": {
"name": "TrainingApp"
}
}The user-facing version identifies a release, for example 1.0.0. Version numbers should follow a consistent release strategy so users and developers can identify updates.
{
"expo": {
"version": "1.0.0"
}
}The iOS build number distinguishes uploaded builds associated with an app version. Each new upload generally needs a build number that meets Apple's versioning requirements and does not conflict with an existing uploaded build.
{
"expo": {
"ios": {
"buildNumber": "1"
}
}
}When using EAS remote version management or automatic increments, verify the effective version and build number rather than assuming the values in the local file are the final values used by the build.
The app icon represents the application on the Home Screen and in other supported iOS interfaces. It should be clear, distinctive, and consistent with the application's identity.
Recommended preparation practices:
{
"expo": {
"icon": "./assets/icon.png"
}
}Verify the file path and image format. Expo may generate or configure platform-specific assets during the build process.
The splash screen is displayed while the application starts. A well-designed launch screen helps establish branding and gives the app a consistent startup experience.
{
"expo": {
"splash": {
"image": "./assets/splash.png",
"resizeMode": "contain",
"backgroundColor": "#ffffff"
}
}
}This example illustrates a simple configuration. Supported splash-screen configuration can depend on the Expo SDK and the installed splash-screen package. Check the current Expo documentation before using additional properties.
The iOS information property list contains application metadata and configuration values. These may include the display name, bundle identifier, permission explanations, supported capabilities, and other platform settings.
In Expo projects, some native configuration values can be set through app.json or app.config.js and applied during the build process.
If an application accesses protected resources, such as the camera, microphone, photo library, or location, it may need the appropriate usage-description strings. The description should explain the actual user-facing purpose of the permission.
{
"expo": {
"ios": {
"infoPlist": {
"NSCameraUsageDescription": "Allow camera access to capture profile photos."
}
}
}
}Include only permissions the app genuinely needs. The example description should be changed if the camera is used for a different purpose.
| Resource | Typical Purpose | Important Consideration |
|---|---|---|
| Camera | Capturing photos or scanning codes | Explain the feature requiring camera access. |
| Photo Library | Selecting or saving images | Use appropriate access and accurate descriptions. |
| Location | Maps, navigation, or location-based services | Request only the level of access required. |
| Microphone | Voice messages or audio recording | Clearly explain when audio capture is used. |
| Notifications | Alerts and updates | Request permission at an appropriate time. |
| Contacts | Contact selection or related features | Explain the purpose and minimize data collection. |
Before submitting an application, document the personal data it collects, uses, shares, and retains. This review must include data collected by third-party SDKs and services integrated into the app, not just data directly handled by your own code.
Potential data categories include:
App Store Connect asks developers to provide privacy information describing the app's data practices. These declarations should accurately reflect what the app and its third-party partners actually do.
A privacy policy should be accessible to users and describe the app's data collection, use, sharing, retention, security practices, and contact information. It should be consistent with the actual implementation and applicable legal obligations.
Provide the privacy policy URL in the relevant App Store Connect field. If the application includes an in-app privacy policy link, ensure it opens successfully.
If an app supports account creation, review Apple's current requirements concerning account deletion. Apps that allow users to create accounts generally need to provide a way to initiate account deletion within the app, subject to Apple's applicable exceptions and guidance.
Test the deletion process end to end, including the backend behavior and any required confirmation steps. Simply logging the user out or disabling the account may not satisfy the applicable requirement.
Code signing allows Apple platforms to verify the identity associated with an application and helps ensure that the app is packaged for an authorized distribution method. A release build must use the appropriate signing configuration.
A distribution certificate is associated with the developer account and is used to sign applications for distribution. Its private key must be protected because unauthorized access could compromise the integrity of the release process.
A provisioning profile connects the app identity with the relevant signing and distribution permissions. The profile used for an App Store distribution build must be appropriate for the intended application and distribution method.
Expo developers can inspect and manage credentials through EAS CLI:
eas credentials --platform iosFollow the interactive prompts to review or configure the credentials for the intended build profile. The exact steps depend on whether the project uses EAS-managed credentials or developer-managed signing.
npm install --global eas-clieas login
eas whoamiIf the project has not been configured for EAS Build, run:
eas build:configureReview the generated eas.json file and confirm that the project is linked to the intended Expo account.
{
"build": {
"production": {
"autoIncrement": true
}
}
}This is a minimal illustrative profile. Real projects may require additional configuration, including version management, environment values, build tool versions, and other settings. Verify the supported schema for the project's Expo SDK and EAS CLI.
eas build --platform ios --profile productionEAS Build prepares and compiles the application using the configured build profile. Monitor the build logs and resolve any reported configuration, dependency, native compilation, or signing problems.
Xcode is Apple's native development environment and can be used to build, archive, sign, and upload an iOS application. This workflow is useful for teams that manage their own native project or need to diagnose native build settings directly.
For an Expo project using Continuous Native Generation, the native iOS project can be generated when required using:
npx expo prebuildReview the project's workflow before running this command because it may create or update native project files. Do not overwrite custom native changes without understanding how they are maintained.
xed iosOpen the appropriate workspace in Xcode. If the project uses CocoaPods, the workspace is generally the correct entry point for the native application.
App Store Connect is Apple's platform for managing app records, uploaded builds, TestFlight testing, product-page metadata, app review submissions, and release settings.
Before uploading a build, create an app record for the application. The record must use the correct platform and match the bundle identifier and relevant developer account.
| Metadata Field | Purpose |
|---|---|
| App Name | Identifies the application on the store. |
| Subtitle | Provides a concise description of the app's value. |
| Description | Explains the app's features and benefits. |
| Keywords | Helps describe relevant search terms within the supported store metadata. |
| Primary Category | Places the app in an appropriate category. |
| Support URL | Provides a place for users to find assistance. |
| Privacy Policy URL | Links to the app's privacy policy. |
| Promotional Text | Highlights timely app information where available. |
| Screenshots | Show the app's interface on supported device sizes. |
| Age Rating | Describes the suitability of the app's content for age groups. |
Apple can change metadata requirements and field limits. Check the current requirements displayed in App Store Connect when preparing a release.
Choose an accurate name and subtitle that explain the product without misleading users. Avoid keyword stuffing, unsupported claims, excessive promotional language, or references to features that are not available.
A useful description often contains:
TrainingApp helps learners organize their study activities
and keep track of their learning progress.
Key features:
- Browse available learning resources.
- Organize learning activities.
- Track progress across supported topics.
- Access account features securely.
For assistance, visit our official support website.This is only a sample. Replace the features with functionality that genuinely exists in your application. Do not submit placeholder copy or claims that cannot be verified.
Screenshots help users understand the app's interface and features before downloading it. They should be clear, accurate, and representative of the actual experience.
Choose screenshots based on the real purpose of the app. Do not include screens that are unavailable to users or depend on unapproved test access.
Analytics, advertising, crash-reporting, authentication, and other third-party SDKs may collect data independently of the app's main business logic. Review their documentation and behavior before completing App Store privacy disclosures.
Apple defines tracking according to its platform policies. If an app tracks users across apps or websites owned by other companies, or engages in other activity covered by Apple's tracking rules, additional disclosure and permission requirements may apply.
Apple reviews applications against its App Review Guidelines. The exact requirements depend on the app's features, business model, target audience, data practices, and distribution method.
Apps selling digital content, subscriptions, or functionality may be subject to Apple's in-app purchase requirements. Rules vary by product, storefront, and applicable exceptions. Review Apple's current guidelines rather than assuming that every payment type can use an external checkout.
If the application uses an external payment provider for eligible physical goods or services, ensure the flow complies with the applicable platform rules and local requirements.
Apps that allow users to publish content may need safeguards such as filtering, reporting, blocking, and contact mechanisms, depending on the feature and Apple's applicable policies.
Use only content, images, logos, music, and other materials that the developer owns or is authorized to distribute. Ensure that the app's name, icon, and metadata do not misrepresent the product or violate another party's rights.
App Store Connect asks developers to answer questions about an app's content and features to determine its age rating. Answer these questions based on the actual application rather than the intended audience alone.
Apps may need to answer questions about encryption and export compliance. The requirements depend on the cryptographic functionality used by the app and applicable regulations.
Do not automatically declare that an app is exempt without checking its actual behavior. If the application uses only standard platform encryption, the applicable declaration may differ from an app that implements or distributes additional cryptographic functionality.
For Expo applications, an Info.plist setting such as ITSAppUsesNonExemptEncryption may be relevant to the declaration process. Set it only when it accurately represents the application's situation and applicable guidance.
Check that eas.json contains an appropriate production profile.
{
"build": {
"production": {
"autoIncrement": true
}
}
}This is a minimal example. Production projects may need additional configuration for environment variables, app versioning, native build settings, and credentials.
eas build --platform ios --profile productionReview the build logs and wait for the build to finish. Resolve any errors before moving to the submission stage.
A successful production build provides an iOS artifact suitable for the configured distribution workflow. A typical App Store submission uses a correctly signed iOS application archive in IPA form. Confirm that the artifact is intended for App Store Connect distribution rather than simulator-only testing.
EAS Submit uploads a supported iOS build to App Store Connect. It works across supported operating systems and can integrate with EAS Build and CI/CD workflows.
eas submit --platform iosFollow the prompts to select a build and configure the required Apple submission authentication. Once the upload completes, Apple processes the build before it becomes available for testing or review workflows.
An optional submission profile in eas.json can store the App Store Connect app ID and other supported submission settings.
{
"submit": {
"production": {
"ios": {
"ascAppId": "YOUR_APP_STORE_CONNECT_APP_ID"
}
}
}
}Replace the placeholder with the actual Apple ID associated with the app record in App Store Connect. Do not confuse this value with the bundle identifier or an Apple Developer team ID.
eas build --platform ios --profile production --auto-submitThis can automate the upload step after the build completes, when the project and submission credentials are configured correctly. It does not automatically guarantee that the application has been submitted for public App Review or released to the App Store.
If you are not using EAS Submit, you can archive and upload the application with Xcode on macOS. If you already have a correctly signed IPA, Apple's Transporter app may also be used to deliver the binary to App Store Connect.
TestFlight is Apple's beta distribution service. It allows developers to distribute eligible builds to internal or external testers before releasing an app publicly.
Internal testing is useful for developers, QA engineers, and team members who need to validate a build before public release.
External testing allows a broader group of testers to evaluate an app. Depending on Apple's requirements, the build or testing setup may need to pass an additional beta review before external distribution.
Record reproducible defects, prioritize critical issues, fix the root cause, and generate a new build when required. Verify that the new build number is appropriate and repeat regression testing before submitting it for review.
After uploading the build and completing testing, open the relevant app record in App Store Connect and complete the required listing information.
Use the review notes field to explain any important information needed to evaluate the app. If access to protected features requires a test account, provide valid review credentials using the appropriate secure fields and ensure the account remains functional throughout review.
Do not include private production credentials, unrelated internal information, or sensitive user data in review notes.
If a feature requires a specific workflow, hardware condition, or test setup, provide concise instructions. Reviewers should be able to understand how to access the app's main features without unnecessary guesswork.
In App Store Connect, select the appropriate app version and attach the processed build to the release. Verify the version and build number before continuing.
App Store Connect may prevent submission when required metadata, privacy declarations, compliance questions, or other information is missing. Review all displayed warnings and resolve the relevant items.
| Status or Outcome | Meaning | Next Action |
|---|---|---|
| Waiting for Review | The submission is waiting for review to begin. | Monitor the status and keep review access available. |
| In Review | Apple is evaluating the submission. | Respond promptly if Apple requests information. |
| Approved | The version has passed review. | Follow the selected release settings. |
| Rejected | The submission did not meet one or more requirements. | Read the resolution details, fix the issue, and resubmit. |
| Metadata Rejected | A metadata or submission issue requires correction. | Update the relevant information and follow App Store Connect instructions. |
Approval and public release are related but separate stages. Depending on the release settings, an approved app may be released automatically, manually, or according to a scheduled release option.
| Problem | Possible Cause | Recommended Solution |
|---|---|---|
| Bundle identifier mismatch | Build configuration differs from the App Store Connect record | Align the identifier and signing setup. |
| Signing failure | Invalid, missing, expired, or mismatched credentials | Review the distribution certificate and provisioning configuration. |
| Duplicate build number | The submitted build number conflicts with an existing upload | Increment the build number using the project's versioning strategy. |
| Build not visible immediately | Apple is still processing the uploaded binary | Wait for processing and check the build status. |
| Missing app metadata | Required listing fields are incomplete | Complete the required App Store Connect fields. |
| Invalid or missing screenshots | Assets do not meet the currently accepted requirements | Review the current screenshot specifications and replace the assets. |
| Privacy disclosure mismatch | Declarations do not reflect actual data practices | Audit app code and third-party SDKs, then update the disclosures. |
| Permission description rejected | Usage text is missing or does not explain the feature | Provide an accurate purpose description and verify permission behavior. |
| App crashes during review | Release-only defect, missing configuration, or unstable dependency | Reproduce the problem, inspect crash logs, and submit a tested fix. |
| Review account cannot sign in | Credentials are invalid or the account requires unavailable verification | Provide a working review account and clear instructions. |
| Incomplete account deletion | Deletion flow is missing or does not perform the expected action | Implement and test the required account-deletion workflow. |
| Payment compliance issue | Payment flow does not comply with the applicable rules | Review the current App Review Guidelines and adjust the flow. |
| Misleading store description | Metadata promises features that are absent or inaccurate | Correct the listing to reflect the actual application. |
Apple generally provides details about the issue that prevented approval. Review the specific guideline or concern cited rather than guessing which change might resolve it.
When responding to App Review, explain the steps taken to address the issue. If the app already complies and the reviewer may have misunderstood a feature, provide clear reproduction instructions and supporting information.
Automation can reduce repetitive tasks and improve consistency across builds. It is particularly useful for teams that release frequently or maintain separate development, staging, and production environments.
# Create an iOS production build
eas build --platform ios --profile production
# Upload a selected build to App Store Connect
eas submit --platform ios --profile productionBefore automating, configure the necessary Apple submission authentication and the appropriate EAS project permissions.
Prepare a sample Expo-based React Native application for iOS distribution, generate a production build, upload it to App Store Connect, test it through TestFlight, and complete the App Review submission steps.
{
"expo": {
"name": "LearningApp",
"slug": "learning-app",
"version": "1.0.0",
"icon": "./assets/icon.png",
"ios": {
"bundleIdentifier": "com.example.learningapp",
"buildNumber": "1"
}
}
}Replace the example identifier with your own unique bundle ID and verify all referenced asset paths.
{
"build": {
"production": {
"autoIncrement": true
}
}
}Use the configuration appropriate for the project's version-management and release strategy.
npm install
npx expo-doctor
npx expo startTest the main screens, authentication, network requests, permissions, and error handling before creating the production artifact.
eas build --platform ios --profile productionMonitor the build logs and verify that the generated artifact has the correct identifier and version information.
Sign in to App Store Connect, create the application record, and select the bundle identifier that matches the production app.
eas submit --platform iosFollow the prompts and wait for Apple to process the uploaded build.
Provide the app description, screenshots, category, age rating, privacy details, support information, and other required fields. Confirm that the information accurately represents the application.
Select the correct build, complete the compliance questions, and submit the version for Apple App Review.
After approval and release, verify the public listing, install the released app where possible, test essential production workflows, and monitor the application's stability.
The project should have a correctly configured iOS application, a signed production build, a completed App Store Connect listing, a tested release candidate, and a documented process for submitting and releasing the application.
Answer: App Store submission is the process of uploading an iOS application to App Store Connect, completing its metadata and compliance information, and sending it to Apple for review before public distribution.
Answer: A bundle identifier uniquely identifies an iOS application and connects its configuration with the appropriate Apple developer and distribution records.
Answer: App Store Connect is Apple's platform for managing app records, uploaded builds, metadata, TestFlight, App Review, and release settings.
Answer: Code signing helps establish the application's signing identity and ensures the build uses the appropriate platform distribution configuration.
Answer: A provisioning profile associates an app identity with the relevant signing certificate and distribution permissions.
Answer: Configure the project and signing credentials, then run eas build --platform ios --profile production.
Answer: Run eas submit --platform ios and follow the prompts to select a build and authenticate the submission.
Answer: TestFlight is Apple's service for distributing eligible beta builds to internal and external testers before public release.
Answer: The version number identifies a user-facing release, while the build number distinguishes uploaded builds and must follow Apple's applicable versioning requirements.
Answer: They tell users and Apple how the app collects, uses, shares, and handles data. They must reflect the behavior of the app and its integrated SDKs.
Answer: Common reasons include crashes, incomplete features, misleading metadata, privacy problems, incorrect permissions, payment-rule violations, and missing review information.
Answer: Review notes provide instructions or context that help reviewers access and evaluate the app's important features.
Answer: Yes. A cloud workflow such as EAS Build and EAS Submit can create and submit iOS builds from supported operating systems without requiring a local Mac for the entire process. A traditional local Xcode archive requires macOS.
Answer: No. Uploading places the binary in App Store Connect. The developer must complete the required listing and compliance steps and submit the version for review. Public release follows approval and the selected release settings.
Answer: Read the rejection details, reproduce the issue, make the required changes, test the fix, and respond through App Store Connect before resubmitting.
Preparing a React Native application for App Store submission requires careful coordination between application development, native configuration, signing, testing, privacy compliance, store metadata, and release management. Developers should verify the bundle identifier, version, build number, app assets, permissions, and production environment before generating the final binary.
Expo developers can streamline the process with EAS Build and EAS Submit, while teams using native iOS workflows can archive and upload applications through Xcode. TestFlight provides a valuable opportunity to test the uploaded build before submitting it for App Review.
A reliable release process includes accurate privacy disclosures, secure credentials, complete review information, tested core features, and a clear response plan for review feedback. Following these practices helps developers prepare professional iOS applications and manage future updates more consistently.
